Rental/car-share vehicle access and management system and method

ABSTRACT

An apparatus and operational method are disclosed that use control hardware resident in a vehicle to enable a remote computing system to wirelessly communicate with the vehicle. The control hardware includes a processor configured to interface with a wireless network and the vehicle through, respectively, a wireless network interface and a vehicle interface. A plurality of CAN (control area network) bus transceivers may exist within the vehicle interface operable to allow the processor to interface with multiple vehicle types. The processor may then be configured to automatically detect an identifier for the vehicle though the vehicle interface and automatically select a CAN bus transceiver from the plurality of CAN bus transceivers based on the detected identifier. The processor can then communicate with the vehicle&#39;s CAN bus via the selected CAN bus transceiver.

CROSS-REFERENCE AND PRIORITY CLAIM TO RELATED APPLICATIONS

This patent application is a continuation of U.S. Ser. No. 15/652,129filed on Jul. 17, 2017, now U.S. Pat. No. 10,515,489, which is acontinuation in part of U.S. patent application Ser. No. 15/154,389,filed on May 13, 2016, now U.S. Pat. No. 9,710,975, which is acontinuation of U.S. patent application Ser. No. 14/315,586, filed onJun. 26, 2014, now U.S. Pat. No. 9,373,201, which is a continuation ofU.S. patent application Ser. No. 13/830,754, filed Mar. 14, 2013, nowU.S. Pat. No. 8,768,565, which claims priority to U.S. provisionalpatent application Ser. No. 61/650,483, filed May 23, 2012, the entiredisclosures of each of which being incorporated herein by reference.

BACKGROUND Technical Field

This invention relates generally to vehicle management systems andmethods and, more particularly, to a Rental/CarShare (RCS) vehicleaccess and management system and method for use and installation.

Description of the Related Art

Currently, RCS companies utilize a vehicle management system thatincludes several hardware modules that are mounted in the RCS vehicle inorder to manage a fleet of RCS vehicles. Such modules are usuallyconnected through the Internet to a remote server containing a vehicledatabase, a customer registration web based interface, and a billingsystem.

The RCS ideal business model requires its vehicles be in service forapproximately 12 months. However, currently, the RCS vehicles are rolledover every 18 to 24 months due to the high labor cost of removing thehardware and re-installing it in a new vehicle, which typically costsabout $85 to remove and $285 to re-install. Thus, the expense and timeintensive installation and transfer process of vehicle managementhardware is a significant burden on RCS companies. In addition, currenthardware to support a management system may be expensive, due tosophisticated hardware and expensive RFID readers, and draw too muchpower.

SUMMARY

Some embodiments of methods and systems in this disclosure overcome theaforementioned problems and are distinguished over the prior art by,among other novel features, an RCS vehicle access and management systemand method for use in the RCS industry that utilizes a controller areanetwork (CAN) bus interface, QR and/or Bar code, RFID/NFC auto detectread/writer, GPS, automatic configuration, and a mobile app coupled witha wireless network that enables the RCS company to monitor and configurethe vehicle.

These preferences also enable customers to bypass the reservation deskand pickup/drop off reserved and non-reserved RCS vehicles using aQR/Bar code, RFID card and/or NFC enabled mobile phone coupled with amobile app. A single control module may include a host processing unitwith a processor, an accelerometer, data storage, a GPS chipset withantenna; a PCB mounted wireless (cellular) modem and antenna, and CANbus transceivers (controller area network) connected with the processor,and a USB programmable interface. The control module may plug into theOBD2 (on-board diagnostics) port of the RCS vehicle. In someembodiments, the RFID/NFC read/write module may be mounted in anaccessible location within the driver's compartment. The onboard controlmodule may be connected by a wireless portal to a remote server orservers. These servers may contain, among other functionality, a vehicledatabase, a customer mobile device interface, SMS gateway, emailgateway, and a billing system. Customers and installers may access thesystem with a variety of methods, including QR code readers, RFID cards,or NFC enabled mobile communication devices. Smartphones, tablets,and/or laptops may interact with the RCS control module by downloading amobile app configured for such interaction.

Another feature and advantage of some embodiments is that they provide amethod of remotely identifying a specific customer and verifying areservation or use of a specific RCS vehicle for a predetermined periodof time.

Another feature and advantage of some embodiments is that they provide amethod of remotely gathering vehicle data and searching the nationalvehicle recall database and displaying that specific vehicle's recallinformation (recall notice, repair status; repaired/not repaired) on amobile device.

Another feature and advantage of some embodiments is that they provide amethod of digitally controlling electromechanical functions(enable/disable starter, door lock/unlock, flash lights, open/closewindows, open/close sunroof, sound horn, pop trunk, etc.) through thevehicle's CAN Bus network; reducing the installation time (direct OBD2plug connection versus hardwiring each control wire to eachelectromechanical function within the vehicle. This reduces theinstallation time (cost) and increases reliability.

Another feature and advantage of some embodiments is that they provide amethod of monitoring, storing and reporting vehicle diagnostics (MIL(malfunction indicator light) such as a “check engine light), airbagdeployed, battery level, etc.), mileage, telltale (e.g., a dashboardindicator such as lights that identify status for blinkers, parkingbrake, cruise control, etc.), speed, location, route driven, geofence,hard/extreme braking and acceleration (onboard accelerometer) inrelation to a specific customers use of a specific RCS vehicle.

Another feature and advantage of some embodiments is that they provide amethod of dynamically pairing a customer's contact information (e.g.,mobile phone number, email address, emergency contact information) to aspecific rental/car-share (RCS) vehicle during their rental period andsending emergency alerts (e.g., email, SMS, voice call) to a specificcustomer's emergency contact list.

Another feature and advantage of some embodiments is that they provide amethod of sending user specific emergency alerts (e.g., location, airbagdeployed, collision or rollover, accelerometer, diagnostic freeze frame,speed, heading, extreme acceleration/braking for a predetermined periodprior to the incident) to a third party emergency dispatch (e.g., 911 orbonded call center) and customers' emergency contacts.

Another feature and advantage of some embodiments is that they provide amethod of gathering and updating and storing vehicle specific data(e.g., location, airbag deployed, collision or rollover, accelerometer,diagnostic freeze frame, speed, heading, extreme acceleration/braking)and onboard data (accelerometer) for a predetermined time period (forexample: every 15 seconds). Upon a collision or roll over the loggeddata can be uploaded via a wireless network to a third party orrecovered via hard wired connection in order to determine the causeand/or fault of the accident.

Another feature and advantage of some embodiments is that they provide amethod of notifying the rental/car-share (RCS) companies of any criticaldiagnostics and/or mileage based maintenance alerts.

Another feature and advantage of some embodiments is that they provide amethod of collecting and storing customer specific vehicle usage data(e.g., fuel level, start/end odometer reading, total miles, hours inuse, max/average speed, idle time, start/stop dates and time, carbonfoot print, driver rating, etc.) for purposes of billing (e.g., invoicebased on hourly usage, mileage or flat day rate). Additional charges ordiscounts can be applied (e.g., User Based Insurance—UBI) for safedriving and safe driving areas (e.g., Location Based Insurance—LBI) ifthe vehicle is used in a high or low risk area.

Another feature and advantage of some embodiments is that they provide amethod of automatically checking out and billing customers when a RCSvehicle is returned. The charge for the rental period can be dynamicallygenerated based, for example, on time used (e.g., hours, days), milestraveled with additional charges for insurance (based on driver ratingand location) and/or fuel (is the tank full; if not, additional chargefor the difference—based on fuel tank level).

A further feature and advantage of some embodiments is that they providea method of enabling the RCS companies to remotely perform locationbased inventory utilizing a Graphic User Interface (GUI), wirelessnetwork and GPS; companies can perform a virtual roll call giving themcount and location of all their vehicles and vehicle status (reserved,not reserved, in use, online, offline, miles to next service and DTCstatus).

A still further feature and advantage of some embodiments is that theyprovide a method of preloading the rental or fleet vehicle's onboardnavigation system with the renter's trip destinations. During thereservation (web based or mobile app) process a renter can select theirdestinations (trip log) during the rental period; the trip log is storedin the customer's database. When the vehicle is checked out via the QRCode, RFID or NFC, the trip log is downloaded to the RCS control modulewhich uploads the trip log to the onboard navigation system.

Neither this summary nor the following detailed description purports todefine the scope of protection. The scope of protection is defined bythe claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a view of the control module as exemplified in one embodiment.

FIG. 2 is a perspective view showing a control module being plugged intothe onboard diagnostics module of a rental/car-share (RCS) vehicle.

FIG. 3 is a perspective view illustrating a rental/car-share (RCS)vehicle having decals with barcodes and/or QR codes.

FIG. 4 is a simplified flow diagram of a network illustrating the flowof data between the rental/car-share (RCS) vehicle and one or moreservers.

FIG. 4A is a block diagram illustrating example remote servers andnetwork used in management of control modules.

FIG. 5 is a series of exemplary graphic user interfaces, as used in oneembodiment, that may be displayed by a mobile app for entering dataduring the unit commission, install, or reinstall process by aninstaller.

FIG. 5A is a series of exemplary graphic user interfaces, as used in oneembodiment, that may be displayed by a mobile app for entering dataduring the unit commission, install, or reinstall process by aninstaller.

FIG. 5B is a flow chart diagram for an example embodiment illustrating amethod of installing and associating a control module within an RCSvehicle.

FIG. 5C is a flow chart diagram illustrating example steps for one ormore embodiments to auto-configure a control module.

FIG. 5D is a flow chart diagram illustrating example steps for one ormore embodiments to auto-configure a control module.

FIG. 5E is a contact layout illustrating a sample embodiment's CAN busPIN configuration.

FIG. 5F is a contact layout illustrating a sample embodiment's automaticCAN bus PIN configuration.

FIG. 6 is an example embodiment's series of displays and menus that areshown on a mobile device by a mobile app for allowing a customer toenter data during a vehicle pick up process.

FIG. 7A-B is an example embodiment's series of displays and menus thatare shown on a mobile device by a mobile app for allowing a customer toreserve a vehicle.

FIG. 8 is an example embodiment's series of displays and menus that areshown on a mobile device by a mobile app for allowing a customer toenter data during a vehicle drop off process.

FIG. 9 is an example flow diagram illustrating the steps of accessing anexample reserved rental/car-share (RCS) vehicle.

FIG. 10 is an example flow diagram illustrating one embodiment's methodfor detection and location of gas availability.

FIG. 11 is a block diagram illustrating computer system configurationsfor various embodiments.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

Overview

This disclosure illustrates a rental/car-share (RCS) vehicle controlmodule, and other related embodiments. The RCS vehicle control modulemay be installed in a rental car or carshare vehicle. The RCS vehiclecontrol module may interact with a mobile application, or multiplemobile applications, in order to provide rental and installationservices. For example, disclosed herein, in one embodiment, a mobileapplication may interact with the control module via one or morewireless networks and/or the Internet in order to unlock the doors,install and associate a vehicle control module within a vehicle, make areservation, access a car with a reservation, and uninstall or transfera vehicle control module. In some embodiments, the vehicle controlmodule may send information to a mobile application, or other outputdevice, about a detected location for a “last chance” to stop for gas(or other service) prior to arriving at a location. In some embodiments,the disclosure herein describes a method for installing a vehiclecontrol module. In some embodiments, the vehicle control module mayautomatically configure itself to interact with its connected vehiclesuch as to unlock its doors or roll down a window. In some embodiments,the vehicle control module may automatically configure itself toappropriately select the correct CAN bus network in a vehicle in orderto accomplish desired functionality.

The terms rental car share (RCS) and RCS vehicle are broad terms thatinclude their ordinary and plain meanings, including, but not limitedto, vehicles rented and leased by traditional car rental services suchas Budget, Enterprise, Hertz, etc., and are returned to locationsusually run by these services. The terms also include vehicles that maybe a part of a car share business model, (e.g. ZipCar, etc) wherecustomers may rent cars on the fly throughout a city or location using amember identification system, and need not return the vehicle to arental service.

Vehicle Control Module

Referring now to FIGS. 1, 2, and 3, some embodiments may comprise ahardware module or control module (e.g. vehicle control module 101). Thevehicle control module may comprise one or more processors (including,but not limited to, special purpose processors or general processors)that control the vehicle control module. For example, vehicle controlmodule may include one or more processors, and one or more storagedevices. The processor(s) may allow the execution of executable computercode capable of instructing the processor to control various aspects ofthe control module and its related peripherals. It also may allow theexecution of computer code configured to interact with other devices ina vehicle, or on the Internet (such as a user with a mobile device, or aserver(s) on the Internet). The vehicle module may also comprise one ormore storage devices, such as a magnetic disk, memory, cache, or anycombination of storage devices. These storage devices may storeinstructions and/or data required for the operation of the vehiclecontrol module.

A vehicle control module may have a variety of connectors to otherrelated devices and peripherals (in some embodiments, these can beconsidered part of the vehicle control module). For example, the vehiclecontrol module may connect to an on-board diagnostic unit (e.g. OBD2port 105), a vehicle starter 107, a door lock/unlock harness 109, anexternal CAN bus harness 102, and an RFID/NFC communications device 104,among others. Not all of these connections need be used. For example, insome embodiments, the door lock/unlock harness 109 need not be connectedto enable functionality to lock and unlock the doors. Instead, in theseembodiments, the doors may be unlocked via the connection to the CANbuss 102 by using specialized command codes.

This method of locking and unlocking the doors saves the installervaluable time. It is often difficult to run wires to all of the doorlocks which are difficult to access in the car. Instead, it is easier toaccess the CAN bus network to interact with the door locks. In addition,other CAN bus operable devices may be accessed through the same CAN businterface. The CAN bus may also provide other functionality, such asenable/disable starter, door lock/unlock, flash lights, open/closewindows, open/close sunroof, sound horn, pop trunk, etc.

As mentioned above, the connection of the vehicle control module to anon-board diagnostic unit such as an OBD2 port 105 is an example of howthe vehicle control module can be connected with a vehicle. It should beunderstood that other connectors could be used to connect the vehiclecontrol module with the vehicle. The vehicle bus to which the vehiclecontrol module connects can be any communication system that transfersdata between components, which may include a variety of hardwarecomponents (e.g., wire, optical fiber, etc.) and software, includingcommunication protocols. Any type of connector suitable for connectingthe vehicle control module to such a vehicle bus could be used as thevehicle bus connector. Examples of vehicle bus technologies include, butare not limited to, LIN (Local Interconnected Network), FlexRay, MOST(Media Oriented System Transport), CAN (Controller Area Network), CAN-FD(Flexible Data Rate version of CAN), USB (Universal Serial Bus), and/orEthernet connections as well as improvements upon such vehicle bustechnologies or future technologies operating as a vehicle bustechnologies. The connection port through which the vehicle controlmodule connects with such vehicle bus technologies can vary as neededfor specific cases.

The on-board diagnostic unit may be plugged into the OBD portconnection. In some embodiments, this may be an OBD2 connection. As seenin FIG. 2, the RCS vehicle control module (herein known as the “controlmodule”) may be plugged into the OBD port 202 of the car. The OBD portmay be used to query a wide range of information from the vehicle,including, but not limited to, vehicle information, such as a VehicleIdentification Number (VIN), Calibration Identification, CalibrationVerification Number, Electronic Control Unit or Module (ECU and ECM)firmware version. It can also query engine performance measures, such ascatalyst counters, the primary oxygen sensor, the evaporating system,EGR system, WT system, secondary air system, secondary oxygen sensor.Other queryable information include vehicle speed, RPMs, odometer, andcurrent fuel level, among others. The OBD port may be connected to otherdevices that may provide functionality such as enable/disabling thestarter, door lock/unlock, flash lights, open/close windows, open/closesunroof, sound horn, pop trunk, etc. While the example embodiment viewedin FIG. 2 shows an OBDII port 202 configured to accept an OBD2connection, it should be understood that this style and type ofconnection may be changed in other embodiments as discussed above.

The control module may also be connected to or comprise a GPS antenna104 and GPS tracking sub-system (internal or external to the controlmodule). Such a subsystem may be configurable to track, using longitudeand latitude, the current location of the control module and attachedvehicle. This information may be queried from the GPS subsystem andaccessed by the control module.

The control module may also comprise, or be connected to, an RFID and/orNFC communications device. RFID (radio-frequency identification) and NFC(near field communication) are methods of querying information from, andcommunicating with, a radio identification device within a setproximity. While RFID usually operates in one direction, NFC istypically used by smartphones for two way RFID type communication. Byconnecting to an RFID or NFC communications device, the control modulemay communicate via RFID or NFC to query identification (or other)information from an installer, car renter, or their devices/smartphones.For example, an installer may use their smartphone to query from thecontrol module a vehicle identifier, or send a user identifier to thecontrol module (other information is also contemplated forcommunication, other than identifiers).

As describe above, the control module may be associated with one or moreidentifiers. These identifiers, in addition or separate from beingqueryable from the control module through RFID, NFC, or wirelessnetworking, may also be available for scan via a bar code or QR code (orany visual representation of the identifier). For example, in FIG. 3, acar with an installed control module appears with a QR code or bar codein the window associated with the CAR and/or control module, or both (itis well known in the art that a bar code or QR code can contain multipleidentifiers). This would allow a smartphone application (such as onethat is programmed to interact with the phones camera to scan bar codesor QR codes), or any QR or barcode reader to scan the codes and receivethe corresponding information, such as control module or vehicleidentifiers. This may enable a mobile app with wireless networkingcapability to use the vehicle or control module identifiers in aninstallation process, or for a customer to bypass the reservation deskand pickup and drop off reserved RCS vehicles.

In some embodiments, the QR code on the window decal replaces a requiredRFID reader. This feature significantly reduces hardware andinstallation costs (by eliminating the expensive RFID and/or NFChardware) and may maintain security by placing the customer at thevehicle.

In some embodiments, no QR code or RFID/NFC communication is needed.Instead, (and this applies throughout the specification when discussingscanning a QR code for a car), in some embodiments, an installer orcustomer could photograph the car's license plate or VIN label via themobile device (e.g. one with a camera). This photo could then beanalyzed by the mobile device or the remote servers to extract the VINor license plate number, the result being input of the vehicle'sidentifier.

The control module may also include, or be connected to, one or moreaccelerometers. Accelerometers can be used to measure vehicleacceleration and deceleration. They allow for evaluation of overallvehicle performance and response. This information can then be used tomake adjustments to various vehicle subsystems as needed. They can alsobe used for modeling and detecting events. For example, given a certainabnormal deceleration detected, the control module may determine thatthe accelerometer detected a vehicle accident. This can be recorded inthe control module and/or reported to the driver, the installer, therental fleet, and/or communicated to a remote server on the Internet.Other events that can be tracked via the accelerometer may include, butare not limited to, unsafe driving habits, vehicle speed, rollover ortilt (e.g. to detect towing) etc. The control module may eithercalculate these types of events themselves using accelerometer data, or,in the case of more sophisticated accelerometers, be informed of (orhave access to) the detected events by the accelerometer.

The control module may also include, or be connected to, wirelessnetworking devices. For example, a PCB mounted wireless (cellular) modemwith internal antenna (or any type of wireless networking, such assatellite, Wi-Fi, or ad hoc networking) may provide communication withthe Internet. For example, the control module may be able to, via thewireless networking device, communicate over a cellular network thatconnects to the Internet. FIG. 4 describes one example of thecommunication that is possible using the wireless capabilities of thecontrol module. For example, the onboard control module is connected bya wireless portal to one or more remote server(s) containing a vehicledatabase, a customer registration mobile device interface, and/or abilling system, among any other features that may be used to managerental or carshare vehicles. Customers and installers can access thesystem with a camera equipped mobile communication device such as amobile phone, tablet or laptop by downloading a mobile app.

Turning to FIG. 4A, which depicts an example layout of remote computingservices for use with the control module, the remote servers maycomprise a number of remote computing devices, including load balancers451, application servers 452, web servers 453, and databases 454. Theseremote servers may be connected using VPN connections 460 to one or morewireless carriers 461 These can be implemented using dedicated or cloudbased servers. A GUI interface to the remote servers may allow anadministrator (472, 473) to manage the clients, devices, and controlmodules via an application, website, or mobile application. In somecases, the remote servers may be known as an RCS gateway. Otherconfiguration of providing remote server services are also contemplated.

To facilitate the transfer of reservation information and telemetricvehicle data between users with authorized access to the control moduleof the vehicle, the application servers may contain additional securitymechanisms to allow or deny such access. The application servers 452 mayemploy security mechanisms including, but not limited to, anauthentication engine, an authorization engine, and an encryptionengine. All information entering the remote servers from an originatinguser or an end user will flow through these engines to verify that sucha user is acceptable and registered for access to the control module.Furthermore, as the vehicle bus connector is envisioned to have auniversal connector configuration for use in many different vehiclemodels and with several alternative vehicle bus technologies, thetransfer and access to telemetric vehicle data can be protected so thatonly authorized users can access and obtain such vehicle information.Further still, authentication procedures can be employed to ensure thatthe control module is authorized to access vehicle information and/orcontrol vehicle functions. An appropriately credentialed control modulecan then interact with various vehicle components to gain informationand control vehicle functions.

The authentication engine of the application servers 452 can beconfigured to authenticate an information transfer request transmittedby the originating user, or the control module of vehicle, to the enduser through the remote servers. Exemplary users may be an accountadministrator accessing the remote servers through the wireless portal,a user on a mobile application installed on a mobile device, or thecontrol module itself equipped within the vehicle. Communicating througha wireless carrier, these types of originating or end users access theauthentication engine of the remote servers when the informationtransfer request is submitted. Operationally as originating users, thesetypes of users may be attempting to contact another end user through thesame wireless carrier or other end users such as operationsadministrators, information technology administrators, or the RCS clientsystem. In other examples, the operations administrators, informationtechnology administrators or the RCS client system may be theoriginating users and connect with the remote servers directly tocontact the end users or the control module of the vehicle through thewireless carrier. Once an information transfer request is receivedwithin the remote servers, the authentication engine performs asystematic analysis of such information to determine the correctidentification of the originating user and the end user for the request.Additionally, the authentication engine evaluates whether such aninformation transfer request is valid. With a positive validation of theinformation transfer request, the authentication engine submits theinformation transfer request into the authorization engine for furtheranalysis.

Within the authorization engine, the remote servers confirm the identityof the originating user requesting the information transfer and/orcontrol module. This may be done through authentication credentials suchas passwords, key codes, or biometric input data sent along with theinformation transfer request by the originating user. After the userand/or control module is authenticated, the remote servers can providecredentials such as an encoded authorization certificate to the userand/or control module that controls access to vehicle information and/orvehicle functions. Additionally the authorization engine may verify theidentity of the originating user requesting the information transferfrom a stored database within the remote servers detailing userspreviously registered and authorized to communication through the remoteservers with end users. Additional information regarding specificinstances of how the authentication engine can verify such access may beseen in example embodiments disclosed throughout this application. Ifthe authorization engine calculates that the originating user is anauthorized user for communication purposes, the authorized originatinguser's information transfer request is validated and passed on to theencryption engine of the security mechanisms within the applicationservers. If it is determined that the originating user requesting theinformation transfer request is not a valid authorized originating userallowed to transmit or receive such information, the informationtransfer request will terminate and a notification may be sent to eachthe originating user and the end user detailing the error of theinformation transfer request. The notification sent to the originatinguser may state that the user is not authorized to access the controlmodule of the vehicle or to send and receive information transferrequests through the remote servers. The end user who was to receive theinformation transfer request may receive a notification statingidentification details related to the unauthorized originating user'saccess attempt including by not limited to the originating user's name,credentials, timestamp of attempted access, and or a location orelectronic address of the originating user attempting access. In suchsituations, unauthorized users attempting to access the remote systemmay be traced and found for possible remediation by the operators of theremote system to determine and correct and close any possibleunauthorized doors or access points into the remote servers.

After a valid authentication is confirmed by the authentication engine,the security mechanisms activate the encryption engine. The encryptionengine parses the information request into a first plurality of segmentswhich are then encrypted and reassembled for transmission to the enduser of the information transfer request. The encryption engine protectsthe transmission of electronic messages in this manner so that only theoriginating user and the end user may access and receive the informationtransfer request. Unauthorized users or additional users connected tothe remote servers will not be able to retrieve or view the encryptedinformation transfer request as they are not identified by theencryption engine as being authorized originating or end users foraccessing the encrypted information. Thus, the encryption engineprovides an additional layer of security to transmission of informationthrough the remote servers which may be prone to outside access attemptsby illegitimate third parties to obtain both control module informationas well as information related to authorized users connected to theremote servers. The end user of the encrypted information will be ableto view such information after the end user is authorized to access theremote servers in the same manner stated above in the authenticationengine. To view such encrypted information, the computing devices ormobile devices which connect to the remote servers may have decryptiontechnology employed therein allowing the end user to access the completeand true version of the information transfer request. When received bythe end user, the encrypted information transfer request is parsed intoa second plurality of segments and decrypted in the same manner as thefirst encryption to retrieve the original information transfer request.Then, the end user may be able to view the original information transferrequest on a graphical computing interface of the computing deviceaccessed by the end user. In operational use, each information transferrequest flowing through the remote servers are subject to the abovedescribed security mechanisms. Given the universal nature of the vehiclebus connector as well as the multitude of users that may connect theremote servers, these security mechanisms provide additional layers ofprotection as the open market compatibility of the control modules maybe employed on various makes, models, years, and types of vehicledesigns.

In the example depicted in FIG. 4 renter may be trying to access arental car. The user's mobile device 162 may be running an applicationthat is capable of reading a QR code on the car that corresponds to thevehicle's identification number (the VIN, or any other number) orcorresponds to the control module's identification number. The mobiledevice 162 or application running on the mobile device, or the customer,may have its own identifier. In this example, the vehicle identifier anda customer identifier may be sent to a remote server via a cellularnetwork and/or the Internet. The remote server may verify that thecustomer identifier sent is a registered customer with the rental orcarshare service, and that customer is allowed to access the identifiedcar. If verification is successful, the remote server may send a command404 to the control module in the car 303 via the Internet. The controlmodule may receive the command via the Internet over its cellularconnection, and unlock the doors, giving car access to the user. Thecontrol module's wireless connection security (e.g. the commands sent tothe control module, etc.) may be protected using host and networksecurity mechanisms known in the art, such as Authentication,Authorization, and Accounting schemes, including PKI,identifiers/passwords, access control lists, etc.

The remote servers in FIG. 4 that the control module may communicatewith may be called remote computing servers, remote computing services,remote servers, remote services, etc. Any type of communication sent orreceived by the control module is subject to security mechanisms of theauthentication engine, authorization engine and encryption enginedescribed above. They may be managed by the rental car share company,the manager or manufacturer of the control modules, or a third party.They may be hosted by a third party hosting service in a locationunaffiliated with the rental/car share company of control modulemanufacturer. Their role is to provide a central repository of vehiclecontrol, and an associated database. For example, programs and data inthe servers may allow a user with a mobile device to communicatedirectly with a control module, even if no RFID, NFC, or any localcommunication between the control module and the mobile device isestablished. This may allow for all remote capabilities to be accessedeither by a user of the car via their smartphones, or by a remote user(such as an operator assisting a customer with a car). For example, anoperator can unlock the car doors for a customer if they have lost theirsmartphone.

The servers may also keep a number of tables and or associations betweenthe cars, control modules, installers, customers, and others as requiredby an RCS system. These associations assist with billing andauthorization/control of car functionality. For example, there may existan association within the server (e.g. in a database table) between avehicle's VIN number and the control module. This assigns the vehicle tothe control module, and the control module to the vehicle. Thus, whenthe control module is sent a command, an embodiment of the inventionwill know exactly which vehicle is being controlled. When a controlmodule is first installed in a vehicle, this association may be created.When a control module is transferred to another vehicle, this vehiclemay be updated to correctly associate the control module to the newvehicle.

There may also exist an association between a user and a control module,or a user and a vehicle (or both). Either association allows for anassociation to be made between all three using the VIN/control moduleassociation described above. This may be created when a user rents avehicle, or makes a reservation. This allows the allocations of users tovehicles and/or control modules. There may also exist an associationbetween an installer or owner of the RCS fleet, and the control moduleor vehicle. Again, this allows a program (such as a web programaccessible through a GUI) to determine the exact vehicles in theinstallers/owners fleet, and the exact control modules belonging orassociated with the installer/owner. This also allows for permissions tobe verified when an installer is creating an association between avehicle and a control module, because ownership of both the controlmodule and the vehicle may be verified prior to making the VIN/controlmodule association.

These, and many other associations also enable billing to take place.The billing software that uses data stored in the remote servers may usethe associations to charge customers or installers/owners, etc. based onthe number of control modules they use or are associated with, or thenumber of vehicles they have rented, or how long those vehicles havebeen rented, etc.

In addition to these associations, any information accessible by thecontrol module may also be uploaded to these servers for access by aninstaller, owner, or user (or any manager of the control modules). Thisdata may include, for example, accelerometer information or its results(such as whether there was safe driving or not, or whether an accidentoccurred, its time/date, etc.), QR Code/RFID/NFC access orcommunication, starts or stops of the vehicle, its GPS location, doorlock or unlock events, etc. Any data accessible by the control module iscontemplated.

Installation/Mobile Installation Application

Current methods of installation may be too labor and time intensive(e.g. 1.5 to 2 hours to install). For example, previous systems forunlocking the doors in RCS vehicles require running hardwires to thedoor lock and unlock motor. Furthermore, previous systems requiredcalibrating a system to current mileage and fuel levels. For example, tocalibrate the fuel level (voltage input from fuel gauge) the installerhad to 1) turn on the engine with an empty fuel tank to sample thevoltage output from the fuel sensor and 2) fill up the gas tank tosample the voltage output when full. After fuel calibration, theinstaller calibrated the mileage using the Vehicle Speed Sense (VSS)output. This requires the installer to drive the vehicle 2 to 3 timesfor over a mile each time. The installer then compared the miles driven(vehicle trip log) with the reported mileage from the device. If theywere within 1% each trip, the device passes. If not, the device iscalibrated and the process is repeated.

In addition, the installer may have to configure a long test andregistration process. After hardware install, the installer will call aremote technician and give them the serial number of a RCS system to betested. The technician will run several tests (to verify connectivity tothe network, GPS and send forward commands to the device) to verify thedevice is installed and functioning. Alternatively, the installer mayregister the device through a website on a laptop or other desktop andperform similar tests. This may add up to 15 minutes per vehicle, andadd considerable cost to a vehicle each time a device is moved from onecar to another.

The systems and methods described herein reduce this install time andcost by eliminating the need to calibrate, and streamlining the testingand registrations process (with a possible savings of 50% time). Forexample, the device does not require calibration because fuelinformation and mileage information may be requested from a diagnosticunit using the OBD2 port (e.g. a CAN Bus). In some alternativeembodiments useful for certain year, makes and models, the controlmodule may request from the odometer a reading over the CAN bus tocalculate miles drive.

Prior to installation, but before registration, an installer may use amobile application (or in a separate mobile application, or webapplication) to interact with the control module based on scanning thecontrol module for an ID. This ID may then be sent to the remote serversso that the remote servers can issue commands to the control module overthe wireless network. The installer may select “test” in the mobileapplication. The installer application may then test the control moduleover a variety of criteria, including whether the control module knowsits serial number, whether the VIN has been automatically detectedcorrectly, whether the VIN and serial numbers for the control module arecorrectly paired, whether the vehicle's command codes or executableinstructions have been found or downloaded (e.g. Learn Mode Successful).It may also test and display results for GPS signal strength, currentaddress, cellular signal strength, battery voltage, etc. Each of thesecategories may have a pass or fail display associated with them thatindicates whether the vehicle has passed or failed testing. If thevehicle did fail some tests, trouble shooting tips associated with thefailed tests may be displayed in the mobile application. If successful,the vehicle may then be registered as described below.

In one embodiment, the registration process may also be improved. Amobile application may be used to accomplish increased registrationefficiency. The following is a brief overview of the mobileapplication's interaction with the control module in order to install ortransfer a control module. The mobile application may be installed on asmartphone, for example, through download of Apple's iTunes service, orany other content distribution mechanism for the mobile device. Theinstaller, after connecting the control module physically with the OBD2port (or other type of vehicle bus connector) (and possibly other inputsdepending on the embodiment) may use the mobile application to initiatean association of the control module. For example, FIGS. 5 and 5A is aseries of displays and menus that are shown on the mobile device by themobile app for entering data during the unit commission (install, FIG.5A) or transfer (uninstall/reinstall, FIG. 5) process by an installer.The displays are only representative, and may be designed in any mannerto carry out the functionality described by the figures and in thisspecification.

Prior to installation of the control module, the control module may bescanned by an installer after it is pulled from inventory. The module,based on the scan, may be assigned by an operator of the remote serveror through the mobile app. In any event, this association between theinstaller and control module is then stored within the remote servers.In addition, the device may be removed from any “unpaid” or“unassociated” inventory in the remote servers' database. At this point,the device may be picked up or shipped to the installer. In addition,the unit ID may then be sent to the installer's mobile app, so that themobile app knows which control modules have been assigned to theinstaller.

Other “inventory” management functionality is also supported through thecombination of an installer's mobile app and the remote servers. Forexample, a control module may be removed from a vehicle for a variety ofreasons (e.g. move to another vehicle, returned to inventory, orreturned for warranty/repair). To move the device between vehicles, a QRcode or bar code may be scanned to get the serial number of the controlmodule. Then, an option to “transfer” or “port” the device may beselected. This will send to the remote servers a command to a listing ofcontrol modules available in inventory. This may then be uploaded to theremote servers where it too may mark the device as available/ininventory to be associated with another vehicle. This may cause thecontrol module to be unpaired with any vehicle, and the associationbetween it and any vehicle in the remote servers database (or theinstaller app) may be removed. The installer may then continue withinstallation/transfer of the device to the new vehicle. When moved toinventory, a similar process occurs. The control module is unpaired withthe vehicle and moved into an available inventory status. For warranty,a similar process occurs, except the control module may be remove frominventory and unassociated with a vehicle.

In some embodiments, when a device is unassociated with a vehicle, theremote servers may alter a billing system so that the rental car companyis no longer charged for service on, or rental of, the unused controlmodule until it is later installed in a vehicle. For example, somerental car companies have over a million vehicles, many of which are ina state of transition. Thus, it is contemplated that costs may bereduced for rental car companies if they do not have to pay a monthlywireless service charge (or other charge) for unused control modules.

After installation of the control module, upon power up, the controlmodule will query the vehicle ECU (electronic control unit) via the OBD2port in order to obtain the Vehicle Identification Number (VIN). The VINis transmitted to the server. The installer may then launch the mobileapplication, and select to “install” or “transfer” the control module(501, 506). The mobile app may then present, to the installer, theopportunity to scan (507, 508, 502, 503) the control module barcode andthe vehicle QR code in order to pair the control module to the QR code(alternative embodiments may use other identifiers to transfer anidentification, such as an RFID, or a visible set of numbers andletters, such as a VIN, that one can input into a mobile device). Thetwo codes may then be sent by the smart phone to the cloud servers viathe smart phone's network to confirm association of the control modulewith the vehicles VIN (which enables association with an installer, aconsumer, etc that tracks vehicles) (e.g. processing 504, 509). Moredetail on the method of querying for the VIN is described herein.

FIG. 5B illustrates a flow chart diagram corresponding to one method forinstalling a control module in a vehicle. The method may start with acontrol module being allocated to a specific installer in the remoteservers (511). After the control module is delivered to the installer,or is somehow put into the possession of the installer, the installermay actually place the control module within the car. This usuallyinvolves mounting the control module within the car. The control moduleis then connected to various parts of the car, including connecting theOBD port of the control module to a diagnostics unit 512. The controlmodule may then also be connected to one or more CAN busses 513 (e.g. soas to access a body control module (BCM) that may control variousfunctionality of a vehicle's body). Connecting the control module to aCAN bus may enable the control module to execute a variety of commandsfor the car, including unlocking the doors or a trunk, controllinglights, chairs, windows, headlights, etc. In some embodiments, theinstaller may mount a QR code for the vehicle on a window or in anyother accessible area 514. At this point the installer may use themobile app described above and scan the QR or bar codes related to thevehicle and the mobile computing device (514 and 515), or any othermethod for gathering the identifiers and sending the identifiers to theremote servers for association. For example, in one embodiment, thecontrol module itself may, upon startup of the car, determine the VIN ofthe car and send the VIN and its own identifier to the remote servicevia a connected wireless network and/or the Internet. Afterinstallation, the control module may be tested 599 (described above),and associated with the vehicle 517 (described above).

In some embodiments, other installation procedures may include mountingan RFID or NFC reader on the car, such as a dashboard, and running aconnecting wire to the control module. The installation process may alsoinclude connecting the control module to the vehicle's starter, ordirectly to the vehicle doors (only used if cannot be controlled throughexternal CAN bus). They also may include mounting a cellular and/or GPSantenna on the dashboard and running a similar wire. In someembodiments, a LED status indicator on the control module housing mayindicate whether the control module is receiving a signal from eitherthe GPS or cellular (or other wireless) network once turned on.

Once installed and associated with a car, any program or device (such asa mobile device running a mobile application) may be able to communicatewith and control the vehicle through the remote service. Any type ofcommunication sent or received can be subject to security mechanisms ofthe authentication engine, authorization engine and encryption engine inthe remote servers. For example, in one embodiment, the remote systemmay communicate over the Internet with a mobile application that cancontrol the car's functionality after authentication and authorizationof the user (such as through a login, where the user is authorized tocontrol the car (e.g. they rented the car), or if the car can tell thatthe user is in close proximity (e.g. the control module has detected theuser, either through a QR/Bar code scan, RFID communication, NFC, or adhoc wireless networking). At this point, the user may control a varietyof functions, depending on its access control, including the list of thefollowing commands: locating the vehicle, such as by sending GPSinformation back to the user, tracking the vehicle via frequent updatesof GPS information, locking or unlocking the doors, unlocking doors foran approved valet, updating a list of RFIDs that are able to access thecar (such as approved user RFIDs (e.g. a member of a car shareorganization), RFIDs associated with maintenance personnel, or a valet),or set settings in the control module, such as for the accelerometer, orto configure whether the control module is tracking mileage.

The control module may also send a variety of data to the user,including car diagnostics, data about a high or low impact crash fromthe accelerometer, a trip log, including start/end locations, date/time,miles driven, duration of trip, max speed, average speed, maxacceleration, fuel level, etc. Other data may include whether extremeacceleration or braking occurred, whether the engine was ever turned onwithout proper access (unauthorized user), the maximum speed, whetherthe vehicle has left a certain geographical area, critical diagnosticinformation (Diagnostic Trouble Code (DTC)) such as whether the car hasa low battery or engine coolant, etc., whether the car has been towed ortampered with, and whether maintenance has been performed.

Auto Configuration

As described above, in some embodiments, vehicle manufacturers broadcastdigital commands over a vehicles CAN Bus network to controlelectro-mechanical functions within a vehicle (example: doorlock/unlock, arm/disarm OE alarm, trunk release, lights, horn, etc.).The digital commands are unique to each year, make and model; therefore,to control functions within a vehicle the device must be able todetermine the vehicles identity in order to load the right commandcodes.

In some embodiments, a manual process may be used to configure thecontrol module. A person or external computer may determine the vehiclesyear make and model, and then connect a control module to a PC via USB,log into a web site on the PC, select the year, make and model, andflash the control module with the selected vehicles codes. Or, in thealternative, the control module may monitor the CAN Bus and determinethe vehicle based on the transmission protocol.

Advantageously, this configuration may also be performed automaticallyby the control module. The control module is capable of storing a set ofexecutable instructions or command codes to use to operate the car inits memory or permanent storage. These command codes or executableinstructions may be organized in storage and mapped according to theirfunctionality. For example, a table or mapping may exist that crossreferences a key for the “unlock doors” command with either the storagelocation for the command code/executable instruction, or thecodes/instructions themselves.

FIG. 5C discloses a method the control module may be automaticallyconfigured to perform in order to determine, store, and access specificinstructions for a specific vehicle. This method may be performed, forexample, on power up (12V supplied to device, e.g., the control moduleis plugged into OBD or or other vehicle bus connector. This may beperformed after every power up, after the power up when newly associatedwith a new vehicle, or if specifically set into “Learn Mode” (e.g. bysuppressing an outside button on the control module to reset and relearnits settings, FIG. 1, 125).

In block 525, the device is powered up, or set into reset mode, whichmay begin the automatic configuration process for learning/looking upthe command codes or executable instructions to operate the vehicle.

In block 526, in some embodiments, the control module will detectwhether or not the ignition has been turned on or the engine has beenstarted. These may be detected by sensing the starter/ignition interruptharness, or by querying information via the OBD2 port (or other vehiclebus connector), among other methods. If one or both of theserequirements have been met (depending on the embodiment), then thecontrol module may continue on to block 527. However, if the requiredsignal is not detected, then the process may stall until the signal isdetected.

In block 527, the control module will request and receive the VIN. Thisis usually performed by querying the Electronic Control Unit/Module(ECU) through the OBD2 port (or other vehicle bus connector). Once theVIN is received, the received VIN may be compared to a previously storedVIN in block 528. The previously stored VIN may have been received froma prior startup or learning mode operation, for example from the samevehicle or a vehicle that the control module was previously installedin. If the vehicle is the same, and the VINs match, then there is noneed to do any auto configuration, and the process may end 536. If theVINs do not match (or if there was no previously stored VIN because thisis a new install), then the control module has been placed in a newvehicle and needs to perform autoconfiguration to determine theappropriate codes to use to automate the vehicle.

In block 529, the new VIN may be saved in memory. This may, in someembodiments, overwrite the old stored VIN, or may be stored in a newmemory location, thus allowing for the control module to record ahistory of VINs that the control module has been associated with.

Block 530 is meant to represent two alternative embodiments. In oneembodiment, a superset of command codes may be stored within the controlmodule in a data store (i.e. magnetic disk, memory, etc). In otherembodiments, the appropriate command codes may be retrieved over thewireless network via download, and stored in the control module forfuture use.

In block 531, if the command codes are stored locally, then the VIN maybe analyzed in order to decode the year, make and model of the vehicle.The Vehicle Identification Number (VIN) is 17 digit number encoded withthe vehicles year, make and model and can be obtain/requestedelectronically when connected to the CAN Bus. Code of FederalRegulations contains information on how to decode the VIN. For example,the 1st character may determine where the vehicle wasmanufactured/assembled. The second two characters of the VIN maydetermine the manufacturer. The 4th-8th characters may determine thebrand, engine, size, and type of vehicle. The 9th character may identifythe VIN as being authorized by the manufacturer. The 10th character mayprovide the model year of the car. The 11th character may indicate whichplant assembled the vehicle, and the final 6 characters may contain theserial number of the vehicle. By using this information, in associationwith a table stored in the control module's data store mapping thevarious codes contained within the VIN, the make, model, and year may bedetermined. Once the year, make and model (YMM) is known, theappropriate YMM may be cross referenced with stored command codes orexecutable instructions for that specific YMM 532. These codes may thenbe referenced in the appropriate memory location (e.g. as the commandtable described above for operating the car) for future use on the CANbus for automated car commands, and the “learn mode” orautoconfiguration may end 536.

In the alternative, (or in the case that the codes for the YMM are notfound already stored within the control module 537), the VIN may beinstead sent via the wireless network connection to the remote computingsystem. The remote computing system 534 may then determine the correctcodes to use, and transmit them to the control module over the wirelessnetwork/Internet. The codes (e.g. command codes or executableinstructions) may be received 535 by the control module and stored in anappropriate table for use to operate the CAN bus and enable carcommands.

FIG. 5D is a flow chart illustrating how the embodiment that downloadsthe codes may function. As explained previously, the control module maypower up or enter learning mode 517. The control module may then querythe ECU via the OBD2 port (or other vehicle bus connector) for thevehicle's VIN 518. The control module then uploads (via the wirelessnetwork/Internet) the VIN to the remote servers, and optionally, a selfidentification code for the control module 519 (or optionally any otheruseful information for the remote servers to use asauthentication/authorization, to verify the pairing between the VIN andthe control module).

In block 520, the remote servers may update the VIN if necessary intheir database. This may occur if, in some embodiments, the remoteservers will update the vehicle associated with the control module basedon a new VIN reported by the control module. This may allow a skip ofusing a mobile application for assigning control modules to vehicles.

In block 521, the remote server may decode the VIN and lookup in itsdatabase the correct command codes and/or executable instructions tosend to the control module. In 522, the remote server uploads thisinformation to the control module. The control module may then downloadand store the codes/instructions for lookup, access, and use whenexecuting certain features, such as unlocking the doors, etc.

In some embodiments, autoconfiguration may also involve configuringhardware for communication with a specific CAN bus networks. Differentmakes (and models) of automobiles utilize different communication busesto achieve similar functions (e.g. unlocking doors, rolling downwindows, unlocking the trunk, etc.). This may provide a challenge whendesigning universal product that is intended to work across all makesand models. This situation actually applies to multiple communicationprotocols within the vehicle—for example, there are single wire & twowire CAN protocols for vehicle. In the examples presented, the focus ison 2-wire CAN buses, however, the same strategy applies to single wireCAN bus and can be extended to other communication protocols as well.

In some embodiments, installers may require knowledge (available via theinstall manual or online vehicle lookup or other) of the vehicle andmust configure the control module manually to use the appropriatecommunication bus. This method can be cumbersome and subject to humanerror. A common implementation is to utilize a dipswitch, which must beset according to the specific vehicle requirements based on thevehicle's type of CAN bus. For example, in some embodiments, the controlmodule may require transmission on at least two CAN bus networks, onefor the ECU and another for the Body Control Module (BCM). For the ECU,the OBD2 harness (or other vehicle bus harness) may be used fortransmission. For the BCM, the external CAN Bus harness may be used fortransmission. However, the installer must configure the DIP switch toisolate the proper communication wires to communicate correctly on theBCM connected CAN bus network.

FIG. 5E shows a typical implementation. In this figure, component 561represents the multiple buses—this is an abstraction, as they are notnecessarily available on the same connector. Component 562 is adipswitch that can be configured according to connected vehicle'srequirements. One example setting would be having the switch for OBDpins 14 & 6 active (ON), while having the other switches inactive (OFF).In this scenario, only 1 bus may be active at a time to avoid joiningmultiple buses on the vehicles (which are intended to be separate). Thecontrol module in this scenario is not aware of which bus it isconnected to.

FIG. 5F shows one example embodiment of an improved solution that can beauto-configured without the need for DIP switches. A control modulewould retrieve the vehicle's VIN and utilize this to determine theappropriate communication configuration. The appropriate vehicleconfiguration can either be stored locally within the control module orbe retrieved remotely via various wireless options, such as thedescribed cellular network and Internet connection. Once theconfiguration is known, the microcontroller would activate theappropriate channel (via channel select pins 575) via a digitalmultiplexer 576 to enable the appropriate CAN transceiver (transceivers577, 578, 579 that can be enabled/disabled by the 1 to 3 MUX 576). Thus,this method eliminates the need for the installer to manually configurethe module's communication setup (requiring costly time and labor on thepart of the installer). This also eliminates the risk of inadvertentlyjoining multiple buses on the vehicle because in this case there can beno common connection point scenarios, which eliminates the chance ofjoining buses. The 1 to 3 multiplexer 576 routes the digital CANcommunications to a single channel that is set via the channel selectlines, which are controlled by the control module. Multiplexer 576, suchas digital multiplexers, to implement this invention are readilyavailable. In some implementations, the MUX can sit on the vehicle sideof the CAN transceiver. This would reduce the number of CAN transceiversfrom 3 to 1. The vehicle side of the CAN transceiver has uniqueelectrical requirements so common readily available multiplexers wouldbe difficult to use.

Customer Mobile Applications

FIG. 6 is a series of displays and menus that are shown on the mobiledevice by a mobile app used by members or customers for a rental serviceor a car share service. The mobile application may allow a customer toenter data during the vehicle pick up process in order to speed up theprocess. For example, a customer may select “pickup” from a list of menuoptions in the mobile application running on their mobile, wirelesslyconnected device 601, 602. The mobile application may then query theuser to scan a QR code, bar code or other identifier associated with thevehicle to be picked up. Using the camera of the mobile communicationdevice, such as a mobile phone, the customer scans the barcode or QRcode on the window decal 603. The QR code is usually placed on therental vehicle, as described above. This will allow the mobileapplication to determine the correct identifier associated with thevehicle. Other methods of input for this identifier are alsocontemplated for this procedure, including, but not limited to NFCcommunication with the control module to transfer the identifier, ortexting a specific phone number associated with the car or rentalservice (the appropriate car may be unlocked via the rental serviceknowing which car was reserved for the user associated with a mobilephone). After the vehicle's identifier has been determined, the mobileapplication may transmit a reservation request and the identifier to theremote servers to verify the person has reserved that vehicle 604. Ifthe remote servers verify the reservation, a confirmation may appear onthe mobile device 605, and the remote servers may command the car, viacommunication with the control module over a wireless network, to unlockthe doors. The control module may then consult the stored command(s)associated with unlocking the cars (as determined based onautoconfiguration for example), and send those commands to the CAN busto unlock the doors. The user may then enter the car, and use the keysfound within to drive the vehicle. The control module may then begin tomonitor driver behavior using the accelerometer and other informationqueried via the OBD2 port (or other vehicle bus connector) or CAN bus,as described above (such as driver habits, going past a geofence (if avehicle departs a preset area, and alert is sent to the installer,remote servers/admins, or the user), diagnostic trouble codes (DTCs), orcollisions.

In another embodiment, the control module may have an RFID reader thatcan detect a mobile device and send the mobile device's ID to the remoteservers (which can then in turn, send the vehicle's ID to the mobiledevice, or immediately confirm the reservation and unlock the doors).

FIG. 7 is a series of example displays and menus that may be shown onthe mobile device by a mobile app used by customers to enter data duringa non-reservation vehicle pick up process. The user may select that heis picking up a car, or that he wishes to reserve a car (701, 702).Using the camera of the mobile communication device, such as a mobilephone, the customer scans the barcode or QR code on the window decal todownload the vehicle information 703. The rental fee and vehiclespecific information may then be displayed for the consumer 704. Thisinformation may have been embedded in the QR code, or may have beenreceived from the remote servers (e.g. the QR code may have contained avehicle ID, which may then be sent to the remote servers, which respondwith information about the vehicle, and may put a temporary reservationon the vehicle until the transaction either succeeds, or iscancelled/times out). The customer may then select or customize certainreservation criteria, such as the length of time to rent/use the car705, accept terms and conditions required by the rental or car shareservice to use the car 706, be offered insurance 707 with its own termsand conditions 708, etc. This information may then be sent to the remoteservers to either confirm or reject the reservation based on thisinformation. To perform this operation, the remote servers may consultwith a third party, such as a rental or car share server, to transactthe reservation. If the reservation is available, and payment succeeds(e.g. a credit card either type into the app or associated with thecustomer is verified), then the reservation may be confirmed. Theconfirmation may be transferred to the mobile device, and may also besent via text or email to the customer email account. At this point, aswith a normal reservation, the doors may be unlocked remotely bycommands sent by the remote servers.

FIG. 8 is a series of example displays and menus that are shown on amobile device by a mobile app for allowing a customer to enter dataduring the vehicle drop off process. When checking out (801, 802), thecustomer may scans the barcode or QR code on the window decal 803 (oruse any other identification mechanism to input an identifier). Thevehicle data and the personal and vehicle specific data is sent to theremote servers via the wireless network. The servers verify the fuellevel (and if not full, charges accordingly), and process the charges onthe credit card of the customer's account 804. The mobile app displays aconfirmation message and sends a receipt to the email address on thecustomer's account or via SMS text.

In some embodiments, the user may receive an access code for frequentaccess to a vehicle during a reservation. A customer may start themobile app, which includes a QR Code scanner and will scan the QR codeassociated with the vehicle from the sticker visible from outside of thecar 1001. (Any other input method may be used, including NFCcommunication, or taking a digital photograph of the car's license plateor VIN and converting that to an identifier, or sending the photographto the remote servers to be converted).

The scanned QR code, or other input may then be decoded to determine thevehicle's identifier. This identifier, along with an identifier of thecustomer may be uploaded to the remote servers via the mobile device'swireless network connection for verification 1002. The customeridentifier may include a phone number/ESN (electronic serial number) andmobile account information, or other identifier. These identifier may beencrypted.

The remote servers may then test to determine whether that customer isin its database based on the identifier provided 1003. If so, and thatcustomer is a valid customer 1003 (e.g. subscribed, up to date onpayments, such checks may require communication with the RCS provider),then the remote server continues on to check for a reservation 1005. Ifthe customer isn't valid, then the customer may receive via the mobileapp an indication that they are not a valid customer 1004 (e.g. theremote server sent back an error message).

If the remote servers' database contains a valid reservation for theidentified car for the identifier customer at or near the time periodthe request is made, then the reservation may be considered valid. Ifnot valid, then the remote system may determine if the vehicle is notreserved 1006 and allow for an immediate reservation to be made 1009. Ifthe vehicle cannot be reserved, the remote system may determine if anynearby vehicles may be reserved, and if so, transfer that informationback to the mobile device, including the location of the proposedvehicles 1008. If no vehicles are nearby that can be reserved, an errormessage is transmitted back to the mobile application 1004. Assuming theinquired vehicle, or nearby vehicles, can be reserved, the remoteservers may initiate the reservation process via the mobile application1009. An example of such a reservation is disclosed herein under thediscussion of FIG. 7.

Once the customer has reserved the vehicle a temporary access code maybe generated by the remote server 1011. The access code may be sent tothe mobile application for storage, along with all relevant reservationdata 1012 (i.e. length of reservation, dates, times, destination,starting places, prices for all services, services included, etc.) Theaccess code may now be used by the customer to begin using the car. Thismay be done in multiple ways. First, the access code itself may betransmitted from the remote servers to the control module. Then, if theaccess code is presented by the mobile device to the control module(e.g. using NFC for example), and it is a match with the access code onthe control module, the control module will unlock all the doors andenables the starter 1013 (e.g. through commands sent to the CAN busesand/or starter as described herein). In some embodiments, the temporaryaccess code may instead be sent from the mobile device to the remoteservers. If the access code matches the access code that the remoteservers have associated with an active reservation, the remote serverswill send a command to the control module to unlock the doors for thecustomer and enable the starter 2013.

When a customer's trip ends 1014 (for example, time of the reservationhas run out and/or the destination has been reached or approached whichcan be tracked via GPS data uploaded to the remote servers from thecontrol module), all relevant reservation in progress data is sent tothe mobile app from the remote servers 1015 (i.e. checkout information,fuel information, etc.). If the customer confirms that the reservationis over, then all end of reservation data may be sent to the mobile app1017, such as the final checkout receipt and inspection of the vehicle.After the reservation is over, the remote servers may send a command tothe control module to disable the starter, lock the doors, and disposeof the temporary access code if any.

In some embodiments, the customer's mobile application may furthercomprise user interfaces and functionality for communication, over thewireless network/Internet, with the rental car service or car shareservice (e.g. their severs) during the rental period. For example, theseuser interfaces may allow a use to terminate a reservation, extend areservation, purchase gas plans or insurance, add new drivers, changereservations, or contact a customer service representative. By puttingthis functionality into an application on a mobile device such as amobile phone, it reduces custom hardware and software requirements byleveraging existing customer hardware. In addition, it saves on wirelessdata costs paid for by the rental/carshare service.

Gas Stop Detection and Notice Nearing Final Destination

In FIG. 10, one embodiment is described where the user may be notifiedabout whether they need to stop for gas prior to returning a vehicle. Inblock 1101, the remote servers may receive a reservation from thereservations system (e.g. the rental company or the car share company'sIT infrastructure). The remote servers may determine the destination forthe car associated with the reservation based on the return site listedin the reservation 1101.

The remote servers, in 1103, may then receive, from the control module(or by looking up in its own database), the reservation trip summaryfrom the previous trip to determine current fuel levels and a locationof the vehicle. A trip summary is a report that may contain data aboutthe current status of a vehicle, including the fuel level, its location,miles per gallon of the vehicle based on the trip, among other data. (Invarious embodiments, this information need not be received via areservation trip summary. Instead, this information (location, fuel,mpg) may be periodically uploaded to the remote servers by the controlmodule, and the same process may be performed).

Regardless of how the data from the control module is sent to the remoteservers, using the vehicles location, the remote servers may calculatethe driving distance of the associated vehicle of the shortest route tothe destination of the new reservation 1104. Based on this distance, andthe mpg of the vehicle, the remote servers may calculate the fuelrequired to reach the destination 1105. If there is enough fuel to reachthe destination 1106, the remote servers may repeat this process 1009.As the vehicle progresses through its trip, it will periodically uploadnew information (new location, new fuel level, optionally new mpg) in anend of trip summary (or any other format). The remote servers may thenrecalculate the distance and fuel calculations to determine whetherthere is enough fuel to reach the destination.

If at any time, it is determined that there is not enough fuel to reachthe destination, the remote servers may calculate the fuel stationclosest to the destination that is still reachable with current fuellevels 1107. This may be performed with geomapping services such asGoogle Maps. The destination may then be transmitted to the user or thecontrol module 1108. For example, the user may receive a text messageabout the current fuel level, the inability to reach the destination,and the location of the calculated fuel station to stop at. This mayinclude a map or other information usable to find the fuel station. Thismay be transferred via SMS, IM, email, or in car display). Thisinformation may also be transmitted over wireless to the control module.For example, the control module may interface with an onboard navigationunit to change the navigation unit to now navigate to the fuel stationinstead of the vehicle's destination.

This process may also apply to other locations besides the finaldestination. For example, a customer may make a reservation and insertinformation into their trip log to indicate multiple destinations. Thedestination used for measuring and comparison in this process can thenbe the next destination instead of the final destination.

This “last chance to get gas” process may be further expandable to otherconsumable services that can be mapped. For example, there may be a“last chance for food” feature where, based on location, destination,and current fuel, the remote servers may be able to inform the customerif they should stop for food in a certain location. Other possibilitiesto consider are rest stops, oil, water, etc.

Other Features

In some embodiments, remote servers will interface with a user's mobiledevice application or other client GUI to gather vehicle and customerdata. The vehicle data may include the destination or drop off locationor lot. The remote servers may then know to forward, and may forward,vehicle maintenance related notifications to the registered recipient atthe destination or drop off location upon the vehicles arrival and/orend of reservation. Arrival may be determined when the vehicle entersthe geofence/geozone associated with the lot, for example, by constantlypolling GPS information in the control module. This may trigger a noticeto a remote server, installer, or user upon arrival.

In some embodiments, a maintenance feature of the control module enablesvehicle maintenance/service personnel to receive geo-specific (vehicleson lots they service) vehicle maintenance alerts (diagnostic troublecode and/or mileage based maintenance). For example, if a vehicles checkengine light is ON, the control module would send a diagnostic alert(e.g. device ID, time/date, location and Diagnostic Trouble Code or DTC)to the remote servers. The remote servers may push (email, SMS and/orsent to a mobile application as a notification) the information toservice personnel assigned to receive vehicle diagnostic alerts at thatthe closest location near the car. The maintenance feature has a Findfeature that will enable the service personnel to navigate to thevehicle on the lot using GPS information from the control module andtransmitted to the installer's mobile device via the remote servers.

Example System Implementation and Architecture

FIG. 11 is a block diagram showing an embodiment of computing device162, and control module 101, which may be in communication with network160 (wireless networks connected to the Internet) and various computingsystems, such as remote servers 970, that are also in communication withthe network 160. The computing device 162 and/or the control module 101may be used to implement systems and methods described herein.

As described above, some embodiments may include portions that areexecuted by the remote servers 970 and/or by the computing device 162and/or the control unit 101, or are entirely executed by the remoteservers 970 or the computing device 162, or the control unit 101. Thus,discussion herein of any structure (e.g. cpu, memory, etc) of thecomputing device 162 or control module 101, or operations performed bythe computing device 162 or control module 101, may be equally appliedto the remote servers 970.

The computing device 162 (e.g. the mobile device that executes mobileapplications described herein) includes, for example, a personalcomputer that is IBM, Macintosh, iOS, Android or Linux/Unix compatibleor a server or workstation. In one embodiment, the computing device 162comprises a server, a laptop computer, a smart phone, a personal digitalassistant, a kiosk, or an media player, for example. In one embodiment,the exemplary computing device 162 includes one or more centralprocessing unit (“CPU”) 905, which may each include a conventional orproprietary microprocessor. The computing device 162 further includesone or more memory 930, such as random access memory (“RAM”) fortemporary storage of information, one or more read only memory (“ROM”)for permanent storage of information, and one or more mass storagedevice 920, such as a hard drive, diskette, solid state drive, oroptical media storage device. Typically, the modules of the computingdevice 162 may be connected to the computer using a standard based bussystem 980. In different embodiments, the standard based bus systemcould be implemented in Peripheral Component Interconnect (“PCI”),Microchannel, Small Computer System Interface (“SCSI”), IndustrialStandard Architecture (“ISA”) and Extended ISA (“EISA”) architectures,for example. In addition, the functionality provided for in thecomponents and modules of computing device 162 may be combined intofewer components and modules or further separated into additionalcomponents and modules, and executed in software, hardware, or acombination of hardware and software.

The computing device 162 is generally controlled and coordinated byoperating system software, such as iOS, Android, Chrome OS, Windows XP,Windows Vista, Windows 7, Windows 8, Windows Server, Windows CE, Unix,Linux, SunOS, Solaris, iOS, Blackberry OS, or other compatible operatingsystems. In Macintosh systems, the operating system may be any availableoperating system, such as MAC OS X. In other embodiments, the computingdevice 162 may be controlled by a proprietary operating system.Conventional operating systems control and schedule computer processesfor execution, perform memory management, provide file system,networking, I/O services, and provide a user interface functionalityusable by the user interface module 110, such as a graphical userinterface (“GUI”), among other things.

The exemplary computing device 162 may include one or more commonlyavailable input/output (I/O) devices and interfaces 910, such as akeyboard, mouse, touchscreen, and printer. In one embodiment, the I/Odevices and interfaces 910 include one or more display devices, such asa monitor or touchscreen 940, that allows the visual presentation ofdata to a user. More particularly, a display device provides for thepresentation of GUIs, application software data, and multimediapresentations, for example. The computing device 162 may also includeone or more multimedia devices, such as speakers, video cards, graphicsaccelerators, and microphones, for example.

In the embodiment of FIG. 11, the I/O devices and interfaces 910 providea communication interface to various external devices. In the embodimentof FIG. 11, the computing device 162 is electronically coupled to anetwork 160 (as shown in FIG. 1), which comprises one or more of a LAN,WAN, and/or the Internet, for example, via a wired, wireless (such as802.11 networks or a cell phone network), or combination of wired andwireless, communication link. The network 160 communicates with variouscomputing devices and/or other electronic devices via wired or wirelesscommunication links.

In some embodiments information may be provided to the computing device162 over the network 160 from remote servers 970. Similarly, in someembodiments, information may be provided to the remote servers 970 overthe network 160 control module 101 or computing device 162. The remoteservers 970 may include one or more internal and/or external datasources. The data sources may include internal and external data sourceswhich store, for example, rental car or car share reservation data, andvehicle, control unit and customer data and properties, and associationsthereof. In some embodiments, one or more of the databases or datasources may be implemented using a relational database, such as Sybase,Oracle, CodeBase and Microsoft® SQL Server as well as other types ofdatabases such as, for example, a flat file database, anentity-relationship database, and object-oriented database, and/or arecord-based database.

In the embodiment of FIG. 11, the computing device 162 includes a userinterface module 912 that may be stored in the mass storage device 920as executable software codes that are executed by the CPU 905. This andother modules in the computing device 162 may include, by way ofexample, components, such as software components, object-orientedsoftware components, class components and task components, processes,functions, attributes, procedures, subroutines, segments of programcode, drivers, firmware, microcode, circuitry, data, databases, datastructures, tables, arrays, and variables. In the embodiment shown inFIG. 11, the computing device 162 is configured to the execute the userinterface module 112 in order to for example, reserve and pickupvehicles, and perform and visualize other operations described herein.

User interface module 912 may generate and render, for example, userinterfaces depicted in FIGS. 5, 7, 8, etc. By interacting with theseuser interfaces, a user of computing device 162 may view variousinformation about their reservation and associated car.

In general, the word “module,” as used herein (except as otherwisedefined, such as in control module), refers to logic embodied inhardware or firmware, or to a collection of software instructions,possibly having entry and exit points, written in a programminglanguage, such as, for example, Java, Lua, C or C++. A software modulemay be compiled and linked into an executable program, installed in adynamic link library, or may be written in an interpreted programminglanguage such as, for example, BASIC, Perl, or Python. It will beappreciated that software modules may be callable from other modules orfrom themselves, and/or may be invoked in response to detected events orinterrupts. Software modules configured for execution on computingdevices may be provided on a computer readable medium, such as a compactdisc, digital video disc, flash drive, magnetic disc, or any othertangible medium, or as a digital download (and may be originally storedin a compressed or installable format that requires installation,decompression or decryption prior to execution). Such software code maybe stored, partially or fully, on a memory device of the executingcomputing device, such as the computing device 162, for execution by thecomputing device. Software instructions may be embedded in firmware,such as an EPROM. It will be further appreciated that hardware modulesmay be comprised of connected logic units, such as gates and flip-flops,and/or may be comprised of programmable units, such as programmable gatearrays or processors. The modules described herein are preferablyimplemented as software modules, but may be represented in hardware orfirmware. Generally, the modules described herein refer to logicalmodules that may be combined with other modules or divided intosub-modules despite their physical organization or storage.

Like the computing device 162, remote servers 970 and control module 101may comprise similar computing hardware, software, and functionality asdescribed above for computing device 162.

Other

Each of the processes, methods, and algorithms described in thepreceding sections may be embodied in, and fully or partially automatedby, code modules executed by one or more computer systems or computerprocessors comprising computer hardware. The code modules may be storedon any type of non-transitory computer-readable medium or computerstorage device, such as hard drives, solid state memory, optical disc,and/or the like. The systems and modules may also be transmitted asgenerated data signals (for example, as part of a carrier wave or otheranalog or digital propagated signal) on a variety of computer-readabletransmission mediums, including wireless-based and wired/cable-basedmediums, and may take a variety of forms (for example, as part of asingle or multiplexed analog signal, or as multiple discrete digitalpackets or frames). The processes and algorithms may be implementedpartially or wholly in application-specific circuitry. The results ofthe disclosed processes and process steps may be stored, persistently orotherwise, in any type of non-transitory computer storage such as, forexample, volatile or non-volatile storage.

The various features and processes described above may be usedindependently of one another, or may be combined in various ways. Allpossible combinations and subcombinations are intended to fall withinthe scope of this disclosure. In addition, certain method or processblocks may be omitted in some implementations. The methods and processesdescribed herein are also not limited to any particular sequence, andthe blocks or states relating thereto can be performed in othersequences that are appropriate. For example, described blocks or statesmay be performed in an order other than that specifically disclosed, ormultiple blocks or states may be combined in a single block or state.The example blocks or states may be performed in serial, in parallel, orin some other manner. Blocks or states may be added to or removed fromthe disclosed example embodiments. The example systems and componentsdescribed herein may be configured differently than described. Forexample, elements may be added to, removed from, or rearranged comparedto the disclosed example embodiments.

Conditional language, such as, among others, “can,” “could,” “might,” or“may,” unless specifically stated otherwise, or otherwise understoodwithin the context as used, is generally intended to convey that certainembodiments include, while other embodiments do not include, certainfeatures, elements and/or steps. Thus, such conditional language is notgenerally intended to imply that features, elements and/or steps are inany way required for one or more embodiments or that one or moreembodiments necessarily include logic for deciding, with or without userinput or prompting, whether these features, elements and/or steps areincluded or are to be performed in any particular embodiment.

Any process descriptions, elements, or blocks in the flow diagramsdescribed herein and/or depicted in the attached figures should beunderstood as potentially representing modules, segments, or portions ofcode which include one or more executable instructions for implementingspecific logical functions or steps in the process. Alternateimplementations are included within the scope of the embodimentsdescribed herein in which elements or functions may be deleted, executedout of order from that shown or discussed, including substantiallyconcurrently or in reverse order, depending on the functionalityinvolved, as would be understood by those skilled in the art.

All of the methods and processes described above may be embodied in, andpartially or fully automated via, software code modules executed by oneor more general purpose computers. For example, the methods describedherein may be performed by the remote servers 970, control module 101,consumer computing device 162, and/or any other suitable computingdevice. The methods may be executed on the computing devices in responseto execution of software instructions or other executable code read froma tangible computer readable medium. A tangible computer readable mediumis a data storage device that can store data that is readable by acomputer system. Examples of computer readable mediums include read-onlymemory, random-access memory, other volatile or non-volatile memorydevices, CD-ROMs, magnetic tape, flash drives, and optical data storagedevices.

It should be emphasized that many variations and modifications may bemade to the above-described embodiments, the elements of which are to beunderstood as being among other acceptable examples. All suchmodifications and variations are intended to be included herein withinthe scope of this disclosure. The foregoing description details certainembodiments of the invention. It will be appreciated, however, that nomatter how detailed the foregoing appears in text, the invention can bepracticed in many ways. As is also stated above, it should be noted thatthe use of particular terminology when describing certain features oraspects of the invention should not be taken to imply that theterminology is being re-defined herein to be restricted to including anyspecific characteristics of the features or aspects of the inventionwith which that terminology is associated. The scope of the inventionshould therefore be construed in accordance with the appended claims andany equivalents thereof.

What is claimed is:
 1. An apparatus comprising: control hardwareconfigured for use in a vehicle to enable a remote computing system towirelessly communicate instructions to the vehicle via the controlhardware, the control hardware comprising: a processor; a wirelessnetwork interface configured to interface the processor with a wirelessnetwork; and a vehicle interface configured to interface the processorwith a controller area network (CAN) bus of the vehicle, the vehicleinterface comprising a plurality of CAN bus transceivers, each CAN bustransceiver configured to interface the processor with a CAN bus type ofat least one vehicle type such that the plurality of CAN bustransceivers are configured to interface the processor with the CAN bustypes of a plurality of different vehicle types in the aggregate;wherein the processor is configured to (1) automatically detect anidentifier for the vehicle through the vehicle interface, (2)automatically select a CAN bus transceiver from among the plurality ofCAN bus transceivers based on the detected identifier, and (3) provide acommunication path between the remote computing system and the vehicle'sCAN bus via the wireless network interface and the selected CAN bustransceiver.
 2. The apparatus of claim 1 wherein the control hardwarefurther comprises a memory in which configuration information for aplurality of different vehicle types is stored, and wherein theprocessor is further configured to (1) determine the vehicle type forthe vehicle based on the detected identifier, (2) retrieve theconfiguration information for the determined vehicle type from thememory, and (3) select the CAN bus transceiver from among the pluralityof CAN bus transceivers in accordance with the retrieved configurationinformation.
 3. The apparatus of claim 2 wherein the storedconfiguration information comprises a plurality of codes for controllinga plurality of vehicle functions, wherein the codes vary by vehicle typesuch that a plurality of different vehicle types exhibit a plurality ofdifferent codes for the vehicle functions, and wherein the processor isfurther configured to (1) receive an instruction from the remotecomputing system via the wireless network interface, the instructioncomprising a command for the vehicle to perform a function, (2) retrievefrom the memory the stored code for the vehicle function correspondingto the received command instruction based on the determined vehicletype, and (3) communicate the retrieved code to the vehicle via thevehicle interface to thereby cause the vehicle to perform the functioncorresponding to the received command instruction.
 4. The apparatus ofclaim 3 wherein the function corresponding to the received commandinstruction comprises a member of the group consisting of (1)enabling/disabling a starter for the vehicle, (2) locking/unlocking adoor for the vehicle, (3) flashing lights for the vehicle, (4)opening/closing a window for the vehicle, (5) opening/closing a sunrooffor the vehicle, (6) sounding a horn for the vehicle, and (7) opening orunlocking a trunk for the vehicle.
 5. The apparatus of claim 3 whereinthe processor is further configured to interact with the remotecomputing system via the wireless interface to be authenticated andcredentialed for accessing the vehicle via the vehicle interface.
 6. Theapparatus of claim 2 wherein the detected identifier is a vehicleidentification number (VIN), and wherein the processor is furtherconfigured to (1) request and receive the VIN from the vehicle via thevehicle interface and (2) decode the VIN to determine the vehicle type.7. The apparatus of claim 1 wherein the processor is further configuredto (1) send the detected identifier to a remote server via the wirelessinterface, (2) receive configuration information for the vehicle fromthe remote server via the wireless interface, and (3) select the CAN bustransceiver from among the plurality of CAN bus transceivers inaccordance with the received configuration information.
 8. The apparatusof claim 7 wherein the control hardware further comprises a memory,wherein the received configuration information includes a plurality ofcodes for controlling a plurality of functions of the vehicle, andwherein the processor is further configured to (1) store the codes inthe memory, (2) receive an instruction from the remote computing systemvia the wireless network interface, the instruction comprising a commandfor the vehicle to perform a function, (3) retrieve from the memory thestored code for the vehicle function corresponding to the receivedcommand instruction, and (4) communicate the retrieved code to thevehicle via the vehicle interface to thereby cause the vehicle toperform the function corresponding to the received command instruction.9. The apparatus of claim 8 wherein the function corresponding to thereceived command instruction comprises a member of the group consistingof (1) enabling/disabling a starter for the vehicle, (2)locking/unlocking a door for the vehicle, (3) flashing lights for thevehicle, (4) opening/closing a window for the vehicle, (5)opening/closing a sunroof for the vehicle, (6) sounding a horn for thevehicle, and (7) opening or unlocking a trunk for the vehicle.
 10. Theapparatus of claim 1 wherein the vehicle interface further comprises amultiplexer, the multiplexer including a data input line, a channelselect input line, and a plurality of channel output lines, each channeloutput line connected to a different CAN bus transceiver, and whereinthe processor is further configured to select the CAN bus transceiverfrom among the plurality of CAN bus transceivers via a control signalapplied to the channel select input line, the control signal causing themultiplexer to connect the data input line with the channel output linefor the selected CAN bus transceiver.
 11. The apparatus of claim 10wherein the channel select input line comprises a plurality of channelselect pins.
 12. The apparatus of claim 1 wherein the processorcomprises a plurality of processors.
 13. The apparatus of claim 1wherein the control hardware further comprises a GPS chipset incommunication with the processor and an accelerometer in communicationwith the processor.
 14. The apparatus of claim 1 wherein the vehicleinterface includes a physical connector, the control hardware configuredto detachably connect with a vehicle bus connector of the vehicle viathe physical connector.
 15. The apparatus of claim 1 wherein the controlhardware does not include a DIP switch configured to provide for manualselection between the CAN bus transceivers.
 16. The apparatus of claim 1wherein the CAN bus transceivers comprise (1) a first CAN bustransceiver that is configured to communicate with a first type of CANbus and (2) a second CAN bus transceiver that is configured tocommunicate with a second type of CAN bus.
 17. The apparatus of claim 16wherein the first CAN bus type is used for communication with anelectronic control unit (ECU) of a vehicle, and wherein the second CANbus type is used for communication with a body control module (BCM) of avehicle.
 18. The apparatus of claim 1 wherein the vehicle interface isfurther configured to interface the processor with another vehicle busof the vehicle, wherein the another vehicle bus comprises at least oneof a LIN (Local Interconnected Network) bus, a FlexRay bus, a MOST(Media Oriented System Transport) bus, a USB (Universal Serial Bus), andan Ethernet bus.
 19. The apparatus of claim 1 wherein the CAN buscomprises a CAN-FD bus.
 20. A network-based method for wireless remotecontrol of a vehicle, the method comprising: authenticating that controlhardware in the vehicle is authorized to access vehicle information andcontrol vehicle functions, wherein the control hardware comprises (1) aprocessor (2) a wireless network interface, and (3) a vehicle interface;interfacing the processor with a wireless network via the wirelessnetwork interface; interfacing the processor with a controller areanetwork (CAN) bus of the vehicle via the vehicle interface, the vehicleinterface comprising a plurality of CAN bus transceivers, each CAN bustransceiver configured to interface the processor with a CAN bus type ofat least one vehicle type such that the plurality of CAN bustransceivers are configured to interface the processor with the CAN bustypes of a plurality of different vehicle types in the aggregate; inresponse to the authenticating step resulting in a determination thatthe control hardware is authorized to access vehicle information andcontrol vehicle functions, the processor (1) automatically detecting anidentifier for the vehicle through the vehicle interface, (2)automatically selecting a CAN bus transceiver from among the pluralityof CAN bus transceivers based on the detected identifier, and (3)remotely controlling a vehicle function of the vehicle by (i) receivingdata over the wireless network via the wireless network interface and(ii) communicating with the vehicle's CAN bus via the selected CAN bustransceiver based on the received data.